With the rapid development of network technology, IPv6 is becoming mature as the next version of Internet Protocol. Since IPv6 can provide more IP addresses and automatic configuration mechanism, various new services (for example, peer-to-peer application) are configured thereon so as to meet a subscriber's different requirements. Thus, accounting various services used by a subscriber becomes a key problem of IPv6.
In order to do the correct accounting, the connectivity time between a subscriber and the network has to be detected correctly. A good connectivity termination detection mechanism should be able to duly detect the abnormal logoffs of the subscriber, for example, the abnormal logoffs due to sudden power off or hardware failure. Then, this mechanism should be able to provide, with respect to such events, basis for service time based accounting, and at the same time, guarantee the safety of using the service by the subscriber, i.e.: the mechanism shall avoid that if subscriber A does an abnormal logoff and this event is not detected, subscriber B may steal the service with subscriber A's IP address.
A conventional Internet Protocol version 4 (IPv4) access network uses a Point-to-Point Protocol (PPP) to monitor a session connectivity via periodic polling, thereby determining whether the connectivity is terminated. However, the following problems arise when a PPP is applied to a PPP-based service mode of IPv6 access networks:
1. Only a 64-bit interface identifier can be negotiated.
As far as an IPv6 terminal (host machine) is concerned, the IPv6 terminal itself can generate a 64-bit interface identifier.
The global IP address of the IPv6 terminal has to be negotiated in other schemes, for example, the auto-configuration scheme of DHCPv6 (Dynamic Host Computer Protocol on IPv6) or stateless auto-configuration scheme. Thus, the complexity of network architecture will be increased if the IPv6 access networks use a PPP-based link detection method.
2. A PPP-based network cannot support multicast data stream.
In a PPP mode, it needs to set up a—layer-2 (or physical layer) PPP link (or PPP tunnel) for each network terminal. When a plurality of terminals in a subscriber network belong to the same multicast group, it needs to duplicate multiple identical multicast data packets in each PPP link (tunnel). Apparently, such a scheme consumes a large amount of bandwidth and fails to make full use of the characteristics of multicast.
In view of the above disadvantages and with the maturity of IPv6, services of access network (e.g. Voice over IP (VoIP) and video-on-demand (VoD)) and various applications are more inclined to use a pure IP approach, i.e. to set up a network connectivity in a non-PPP approach. Since the use of DHCPv6 can realize authentication, service selection and IP address allocation more conveniently, the service mode based on DHCPv6 develops gradually. In this service mode, once the terminal of a DHCPv6 is re-connected to the network, an available IP address (which is used in limited lease time) is automatically allocated from the public IP address pool of a device named as DHCPv6 server and the additional IP configuration information is delivered to the DHCPv6 terminal. Thus, the function of “plug and play” of an IPv6 network can be realized without configuring the DHCPv6 terminal manually.
FIG. 1 schematically illustrates a structural diagram of an IPv6 access network based on DHCP service mode, wherein an access node 101 serves as an IPv6 router to manage the whole access network and control the automatic configuration of services. The DHCPv6 server (not shown) or DHCPv6 proxy (not shown) can be located in the access node 101. The DHCPv6 server uses the state DHCPv6 auto-configuration mechanism to allocate to subscriber terminal 1 . . . n IPv6 addresses and other configuration messages, for example, DNS server address or SIP server address.
With regard to reclaiming resources, usually the DHCPv6 server terminates the connectivity of DHCPv6 to thereby release corresponding resources after receiving the DHCP RELEASE message sent from the terminal. When the connectivity is abnormally terminated, the DHCPv6 server can use a timeout mechanism to process this state. The timeout mechanism controls connectivity states of links in the network by setting lease time for IP addresses. The lease time of IPv6 address in DHCPv6 is usually much longer than that prescribed in the timeout mechanism of the PPPv6 link control protocol and is generally in the order of hour. Apparently, as stated above, such a lease time is hard to satisfy the requirements of safety and accounting. Nevertheless, setting the lease time as one minute is not realistic either, because this will force the DHCPv6 server to allocate IP addresses to the terminal frequently.
According to the specification of RFC 2641, a neighbor cache list is maintained in the access node 101. In this list, there is an entry corresponding to each subscriber terminal, identifying the state whether the subscriber terminal is reachable to the access node 101. All the fields in the entries of the neighbor cache list are shown in FIG. 2A.
In FIG. 2A, according to the specification of RFC 2641, the entries of the neighbor cache list may include a plurality of different fields, wherein an “IPv6 address” field identifies the address of the subscriber terminal to which this entry corresponds. As for each subscriber terminal whose connectivity is not terminated, the neighbor cache list has respectively a corresponding entry. A “Neighbor_State” field identifies whether the subscriber terminal is reachable and may have the following states:
1. Reachable
Within the “ReachableTime” after receiving a positive confirmation indicating that the neighbor is reachable, a “Neighbor_State” field is set as a “REACHABLE” state, showing that the subscriber terminal is reachable within this period of time. In this state, no particular operation is performed when the packet data is transmitted. If the positive confirmation is received once again within the “ReachableTime”, the system will reset time. The RFC 2461 defines the “ReachableTime” whose default value is uniformly distributed between 15 seconds to 45 seconds.
2. Stale
If no reachable positive confirmation is received again within the “ReachableTime” after receipt of a positive confirmation indicating the neighbor is reachable, the “Neighbor_State” field enters a “stale” state. When the state is “stale”, any operation is not performed until data is transmitted.
3. Delay
If, in the “stale” state, there are data packets to be transmitted, the “Neighbor_State” field enters a “DELAY” state. This state will last at most “DELAY_FIRST_PROBE_TIME”, i.e. 5 seconds. During this period of time, it comes into the “PROBE” state if no reachable confirmation is received.
The “delay state” is an optimum state, and the existence thereof makes the upper layer protocol (for example, three-way handshake mechanism of TCP) acquire additional time, thereby expecting the confirmation that the neighbor is reachable.
4. Probe
If the confirmation that the neighbor is reachable is not acquired in the “DELAY” state, the “Neighbor_State” field is set as a “PROBE” state. In this state, a neighbor request is issued every fixed time (default value is 1000 ms) to expect a reachable confirmation.
Using the entries in the aforesaid neighbor cache list, it may detect whether a subscriber terminal is reachable when downlink data is ready to be transmitted in the network. However, in the case that the network has not transmitted downlink data for a long time, it is impossible to learn whether the subscriber terminal is reachable since the access node will not probe the connectivity situation of the subscriber terminal on its own initiative. During this period of time, the subscriber is likely to be logoff abnormally. The aforesaid situation of insecurity will happen if the connectivity of the subscriber terminal is not terminated duly and accurate accounting cannot be executed.
How to strike a balance between the processing requirements and resources consumption has become an urgent problem to be solved in the IPv6 access networks.